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1  Release  Notes 


The  sections  in  this  chapter  provide  information  about  ModSAF  distribution  and  documenta¬ 
tion.  They  also  provide  instructions  for  installing,  building,  operating,  and  porting  the  ModSAF 
application. 


1.1  Distribution 

There  are  two  ModSAF  1.0  software  distributions.  The  source  code  distribution  contains  all  the 
source  files  needed  to  build  the  ModS.\F  program,  and  all  the  data  file  needed  to  run.  Executa¬ 
bles  must  be  compiled  after  software  installation.  The  executable  distribution  contains  all  of  the 
executable  and  data  files  needed  to  run  the  ModSAF  program. 


The  distribution  includes  150  libraries  and  a  source  directory  which  break  down  as  follows: 

Total  lines  -  326335 

Whitespace  «  43336 
Coments  ■  67393 
Inline  «  5062 
C  >  210544 

Source  (C  *  Inline)  ■  215606 

Percentage  whitespace:  13.28  X 
Percentage  comments:  20.65  X 

Percentage  C:  66.07  X 

Total  lines  in  data  files  •  27808 

Total  lines  of  TeXinfo  documentation  «  103256 


The  root  of  the  distribution  limM  tury  ^trurturc  is  called  ‘common/’.  This  directory  contains  the 
subdirectories  which  are  describ«-il  m  ihi*  following  sections. 
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1.1.1  tools 

Each  ‘Makefile’  in  the  ModSAF  source  tree  references  a  common  set  of  compiler  configuration 
files.  These  files  specify  which  compiler  to  use,  what  flags  to  specify,  and  the  steps  required  to 
compile  and  install  software  archives,  executables,  documentation,  and  data  files. 


The  ‘tools’  directory  contains  the  compiler  configuration  files.  Included  in  the  configuration 
files  is  the  following: 

•  Configuration  for  Mips  Magnum  or  M/2000  systems,  using  RISC/OS  4.50,  4.51,  or  4.52.  cc 
version  2.11  is  required. 

•  Configuration  for  Silicon  Graphics  hardware  and  operating  system. 

•  Configuration  for  Sun  4  systems,  using  the  Gnu  gcc  compiler.  The  native  Sun  compiler  can 
probably  also  be  used,  with  some  modification  of  the  files  in  this  directory  (see  Section  1.5 
[Porting  ModSAF  1.0],  page  21). 

•  Prototype  configuration  for  IBM  AIX  systems. 

The  Mips,  SGI  and  SUN  configurations  are  officially  supported.  Portions  of  the  ModSAF 
software  have  been  compiled  and  run  on  IBM,  and  HP  systems,  but  the  full  system  has  not  been 
built  or  tested.  The  tools  directory  is  not  included  in  the  executable  version  of  ModSAF  1.0. 


1.1.2  libsre 

The  directory  ‘comaon/libsrc’  contains  the  sources  for  all  the  software  libraries  which  make 
up  the  ModSAF  system.  The  ModSAF  architecture  is  built  up  from  many  libraries  (150  in  the 
ModSAF  1.0  distribution).  Most  of  these  (142)  are  considered  ModSAF  compliant,  which  means 
they  meet  a  set  of  coding  standards  which  are  spelled  out  in  another  document  (see  section  ‘Coding 
Standards’  in  Software  Architecture  Design  and  Overview  Document).  The  remaining  libraries 
(8)  are  legacy  from  the  SIMNET  project,  and  have  been  used  without  modification  in  ModSAF. 
During  the  initial  build  process,  the  file  ‘common/libsrc/modBaf  .libs’  is  created  which  contains 
a  list  of  the  ModSAF  compliant  libraries.  None  of  the  ‘conmon/libsrc’  libraries  are  included  in 
the  executable  version  of  ModSAF  1.0. 

Overviews  of  the  functionality  of  these  libraries  can  be  found  in  the  topmost  ModS.AF  info 
node,  modsaf dir. 
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1.1.3  include 

The  directory  ‘cojnmon/ include’  contains  two  source  subdirectories: 

‘common/ include/global  ’ 

This  directory  contains  globally  referenced  C  header  files,  which  contain  definitions  of 
physical  constants,  conversion  factors,  dynamic  memory  allocation  conventions,  and 
type  definitions. 

‘  common/ include /protocol  ’ 

This  directory  contains  the  definition  of  the  DIS,  SIMNET,  and  PO  protocols,  as  well 
as  definitions  of  many  experimental  protocols  which  have  been  used  in  SIMNET. 

In  addition,  there  is  the  directory  ‘common/include/libinc’  where  the  C  header  files  defined 
by  the  various  libraries  are  deposited  as  part  of  the  compilation  process. 

The  directory  ‘common/ include’  is  not  included  in  the  executable  version  of  ModSAF  1.0. 


1.1.4  data 

The  directory  ‘common/data’  acts  as  a  repository  for  data  files  defined  in  the  ModSAF  libraries. 
Data  files  are  copied  from  library  directories  into  this  directory  during  the  compilation  process. 
The  files  in  this  directory  can  be  identified  by  their  extensions: 

‘.rdr’  Data  files  formated  using  the  ‘libreadar’  format.  These  data  files  are  used  by  the 
simulation  and  workstation  applications  at  run  time. 

‘  .xrdb’  X  windows  resource  definition  database  files.  These  data  files  are  incorporated  into  the 
X  Server  Resource  Database  at,  or  just  prior  to,  run  time. 

‘.map’  A  binary  format  used  by ‘libhffl’. 


1.1.5  lib 

The  directory  ‘common/lib’  contains  a  subdirectory  structure  which  acts  as  a  repository  for 
compiled  software  library  archives  (arCD).  The  directory  structure  is  constructed  automatically 
as  part  of  the  compilation  process.  First,  there  are  subdirectories  for  each  architecture  which  is 
built.  The  architecture  is  specified  via  the  environment  variable  BUILD.ARCH  and  should  have  one 
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of  the  values:  sgi,  mips,  8un4,  or  aiz.  If  you  use  csh  or  tcsh,  this  can  be  set  in  the  ‘.cshrc’  file 
in  your  home  directory  using  the  command: 

s«t«nv  BUILD.ARCH  sgi 

(Substitute  your  own  architecture  for  sgi.)  If  you  use  sh  or  ksh,  this  can  be  set  in  the  ‘  .prof  ile’ 
file  in  your  home  directory  using  the  command: 

BUILO.ARCH-sgi 
•zport  BULD.ARCH 

The  ‘.cshrc’  modifications  are  made  automatically  upon  execution  of  the  ‘mahe-all’  script  (see 
Section  1.3  [Building  ModSAF  1.0],  page  9). 

Below  the  architecture  directory,  you  will  find  a  subdirectory  which  is  specific  to  the  application 
configuration  which  is  built.  For  ModSAF,  this  will  always  be  called  ‘modsaf This  name  comes 
from  a  configuration  file,  which  is  also  indicated  by  an  environment  variable.  For  csh  or  tcsh  users, 
this  should  be  set: 

setenv  BUILD.APP  src/NodSAF/modsaf .config 

For  sh  or  ksh: 

BUILD. APP«src/HodSAF/modsaf . config 
•zport  BUILD.APP 

As  with  the  BUILD.ARCH  variable,  this  is  automatically  place  in  your  ‘.cshrc’  by  ‘make-all’. 

The  files  in  the  application  subdirectories  are  merged  into  the  ModSAF  executable,  by  the  linker 
(IdCl)).  This  directory  is  not  included  in  the  executable  version  of  ModSAF  1.0. 


1.1.6  info 

The  directory  ‘common/info’  contains  the  ModSAF  documentation  in  Emacs-info  format.  The 
files  in  this  directory  are  compiled  from  ‘.tszinfo’  files  in  the  library  and  source  directories,  and 
are  installed  during  the  compilation  process. 
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1.1.7  src 

The  directory  ‘comaon/src’  contains  sources  for  building  executable  programs  and  operating 
system  related  modules: 

‘coflDBon/src/NodSAF’ 

This  directory  contains  the  following: 

•  The  ModSAF  executable  program  and  compilation  script. 

•  The  ‘conmon/arc/ModSAF/entities’  subdirectory  which  contains  vehicle  param¬ 
eter  files. 

•  The  ‘conmon/src/ModSAF/docs’  subdirectory  which  contains  the  top-level  Mod¬ 
SAF  1.0  documentation. 

^coamon/src/interck’ 

The  source  and  executables  for  the  interck  bug  finder  program  reside  in  this  directory. 
This  directory  is  not  included  in  the  executable  version  of  ModSAF  1.0. 

‘common/ arc/blaster’ 

The  source  and  executables  for  the  network  blaster  program  reside  in  this  directory. 
This  directory  is  not  included  in  the  executable  version  of  ModSAF  1.0. 

‘common/arc/OSAtamplata’ 

This  directory  contains  the  template  files  used  by  the  osatemplata  script  found  in  the 
bin  directory.  This  directory  is  not  included  in  the  executable  version  of  ModSAF  1.0. 
‘common/arc/loggar’ 

The  logger  source  files  and  executable  program  reside  in  this  directory. 

‘common/ src/cmc’ 

‘common/arc/aimla’ 

These  directories  contain  C  header  files  and  compiled  operating  system  modules.  These 
directories  are  not  included  in  the  executable  version  of  ModSAF  1.0. 
‘common/arc/dapends’ 

depanda  is  a  program  which  examines  ModSAF  compliant  software  directories  and 
identifies  the  dependencies  between  them.  It  is  used  to  do  ordered  compilation,  build 
Makefiles,  and  generate  FIG  format  dependency  graphs.  This  directory  is  not  included 
in  the  executable  version  of  ModSAF  1.0. 

‘common/ arc/public’ 

The  ‘common/arc/public’  directory  contains  public  domain  source  files  for  xinfo, 
makainfo,  and  maka-3.68. 

•  xinfo  is  a  public  domain  X  windows  interface  tool  for  reading  Emacs-info  format 
documentation  without  using  emacs.  It  is  included  as  a  convenience  for  reading 
the  ModSAF  documentation. 
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•  maksinfo  is  a  public  domain  tool  for  creating  Emacs-info  format  documentation 
from  our  texinfo  documentation. 

•  mak«-3.68,  also  known  as  gmaka,  is  a  public  domain  make  tool  used  in  building 
the  ModSAF  application. 

The  compiled  versions  can  be  found  in  the  ‘common/bin’  directories.  These  sources 
are  provided  as  a  convenience  to  the  ModSAF  customer  and  are  not  supported.  This 
directory  is  not  included  in  the  e.xecutable  version  of  ModSAF  1.0. 


1.1.8  bin 

The  directory  ‘common/bin’  contains  subdirectories  for  each  of  the  supported  architectures: 
sgi,  mips,  8un4,  aix.  As  explained  earlier  (see  Section  1.1.5  [lib],  page  3),  this  is  specified  by  the 
environment  variable  BUILD.ARCH.  Since  this  directory  contains  executable  programs  which  are 
needed  to  compile  ModSAF,  it  should  be  added  to  your  program  search  PATH.  For  csh  or  tcsh 
users,  this  is  done  by  adding  it  to  the  ‘ .  cahrc’  file.  For  example: 

sat  path  ■  (/usr/staff/mynaBa/coBmon/bin/sgi  .  /bin  /usr/bin  /usr/bin/Xll) 

For  sh  or  ksh  users,  the  syntax  is: 

PATH^/uar/staf f /Bynana/coHon/bin/sgi : : /bin : /usr/bin : /usr/bin/Xi 1 
export  PATH 

For  csh  or  tcsh  users,  the  ‘nako-all'  script  will  place  the  correct  directory  in  your  path. 

The  ‘conmon/bin/<BUILD.ARCH>'  subdirectory  contains  an  awk  script  ‘fsin2ch.avk’,  which  is 
used  during  the  compilation  of  ModSAF  task  libraries.  The  'fso2ch.awk’  file  is  originally  located  in 
‘conmon/libsrc/libtask’  directory  and  is  installed  in  the  correct  'common/bin’  subdirectory  upon 
running  the  make-all  script.  The  directories  in  ‘coomon/bin’  also  act  as  a  repository  for  compiled 
executables,  such  as  the  ‘depends’  program,  ‘makainfo’,  ‘gmake’,  and  ‘xinf  o’.  The  executables  for 
‘makeinfo’,  ‘gmake’,  and  ‘xinfo’  along  with  the  ‘osatemplate’  script  are  distributed  in  the  correct 
‘common/bin’  subdirectory. 


1.1.9  terrain 

The  directory  ‘common/tarrain'  < ontains  a  subdirectory  for  each  terrain  database.  The  distri¬ 
bution  includes  the  following  databa.s<'s: 
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‘cojBmon/t«rrain/hunt«r-01 10’ 

A  version  of  the  50KM  x  50KM  Hunter-Liggett  terrain  database. 
‘coiimon/t«rrain/itsec93-0101’ 

A  lOOKM  X  lOOKM  superset  of  the  Hunter-Liggett  terrain  database  for  use  at  the 
I/ITSEC  ’93  show. 

‘  common/t «rr ain/nt c-0 1 0 1  ’ 

A  version  of  the  50KM  X  50KM  National  Training  Center  terrain  database. 

‘  common/ 1  errain/lmox-03 1 1  ’ 

A  version  of  the  50KM  x  75KM  Ft.  Knox,  Kentucky  terrain  database. 


1.1.10  profiles 

The  directory  ‘common/profiles’  is  created  when  the  ModSAF  program  is  hrst  run,  to  hold 
user-customization  prohle  files. 


1.1.11  scenarios 

The  directory  ‘common/scenarios’  is  created  when  the  ModSAF  program  is  first  run,  to  hold 
user-created  scenario  files. 
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1.2  Executable  Version  of  ModSAF  1.0 

The  directories  included  in  the  executable  version  of  ModS.\F  1.0  are: 


comnon/data 

common/ info 

common/t  errain 

common/t«rrain/huntar~01 10 

common/t  arrain/nt  c -0 1 0 1 

common/t«rrain/knox-03 1 1 

common/src 

common/src/logger 

common/src/ModSAF 

common/scenarioB 

common/prof il«8 

common/ovarlays 

common/logs 


The  following  steps  should  be  followed  to  load  the  ModSAF  1.0  program  from  the  distribution 
tape: 


Getting  Started 

Choose  a  directory  location  on  your  machine  for  the  executable  code  to  reside  in,  such 
as  Vusr/staff /mynama/modsaf Do  not  instaJl  the  ModSAF  1.0  distribution  "over" 
a  previous  ModSAF  release.  Make  sure  you  are  in  this  directory  before  you  begin  the 
next  step. 

Unloading  the  tape  requires  approximately  50  Mbytes  of  disk  storage  for  the  executables 
and  the  terrain  databases. 

Load  the  software 

Load  ModSAF  1.0  Tape  in  tape  drive.  If  you  are  on  an  SGI  machine,  unload  the  tape 
as  foUows: 

for  builtin  drive: 

tzir  zvf  /dev/tapens 

for  external  SCSI  bus  tape  drive  (replace  #  with  SCSI  device  number) 
tau:  xvf  /dev/mt/tpsOdins 
If  you  are  on  a  Mips  machine,  unload  the  tape  as  follows: 
tar  xvf  /dev/rmt/ctapeO 

The  name  of  the  tape  device  differs  on  other  machines.  Once  the  executables  are  installed  skip 
ahead  to  the  running  instructions  (see  Section  1.4  [Running  ModSAF  1.0],  page  14). 
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1.3  Building  ModSAF  1.0 

The  following  steps  should  be  followed  to  build  the  ModSAF  1.0  program: 

Getting  Started 

Choose  a  directory  location  on  your  machine  for  the  source  code  to  reside  in,  such  as 
‘/usr/ataff/mynaine/modsaf Do  not  install  the  ModSAF  1.0  distribution  "over"  a 
previous  ModSAF  release.  Make  sure  you  are  in  this  directory  before  you  begin  the 
next  step. 

Unloading  the  tape  requires  approximately  80  Mbytes  of  disk  storage  for  source  code, 
executables,  documentation,  and  the  terrain  databases.  Once  fully  compiled,  approxi¬ 
mately  170  Mbytes  of  disk  storage  is  consumed  by  the  source  code,  object  code,  terrain, 
and  documentation. 

All  the  executable  programs  (‘zinfo’,  ‘gmake’,  ‘osatemplate’,  ‘makeinfo’)  which  are 
needed  to  build  ModSAF  are  on  this  tape. 

The  build  process  assumes  the  machine  has  a  C  compiler. 

Load  the  software 

Load  ModSAF  1.0  Tape  in  tape  drive.  If  you  are  on  an  SGI  machine,  unload  the  tape 

as  follows; 

for  builtin  drive: 

tar  xvf  /dev/tapens 

for  external  SCSI  bus  tape  drive  (replace  #  with  SCSI  device  number) 
tar  xvf  /dev/rmt/tpsOdfns 
If  you  are  on  a  Mips  machine,  unload  the  tape  as  follows: 
tar  xvf  /dev/rmt/ctapeO 

The  name  of  the  tape  device  differs  on  other  machines. 

This  will  load  all  the  ModSAF  software,  as  described  in  the  previous  section.  On  an 
SGI  machine,  the  system  may  ask  you  to  supply  a  second  tape.  Ignore  this  request  by 
hitting  return. 

Prepare  your  environment 

The  compilation  of  ModSAF  requires  that  a  few  environment  variables  be  set  (see 
Section  1.1.5  [lib],  page  3).  The  values  you  should  use  for  these  environment  variables 
depends  upon  the  architecture  you  will  be  running  on  and  the  way  you  will  be  using 
the  ModSAF  program.  The  ModSAF  program  can  be  built  many  different  ways  within 
the  same  source  hierarchy.  For  example,  executable  versions  of  ModSAF  for  both  a 
Sun  4  and  an  SGI  can  be  built  from  the  same  set  of  sources. 

The  architecture  is  set  via  the  environment  variable  BUILD.ARCH. 
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Most  ModSAF  1.0  users  should  build  the  application  using  the  standard  application 
configuration,  described  by  a  file  in  the  application  source  directory 
‘src/ModSAF/inods2rf.config’.  This  file  specifies  the  set  of  compilation  flags  which 
select  which  features  are  enabled  and  which  are  not.  There  is  another  configuration, 
called  ‘src/ModSAF/safsim.conf  ig'  which  builds  the  application  without  X  windows. 

The  application  is  set  via  the  environment  variable  BUILD.APP. 

Many  programs  used  in  the  compilation  of  ModSAF  are  installed  in  the  directory 
‘common/bin/<BUILD_ARCH>’.  This  must  be  in  your  PATH  for  compilation  to  succeed 
(see  Section  1.1.8  [bin],  page  6). 

The  ModSAF  program  is  very  large,  and  many  compilers  will  need  extra  disk  space 
to  build  it.  Most  architectures  support  an  environment  variable  called  TMPDIR  which 
specifies  a  directory  in  a  large  disk  partition.  You  will  probably  need  to  specify  such  a 
directory.  For  example: 

setenv  TMPDIR  /usr/tn^ 

Finally,  you  must  select  a  set  of  EXTRA.CFLAGS  to  suit  your  needs.  This  environment 
variable  specifies  extra  flags  which  are  passed  to  the  C  compiler  when  the  program  is 
built: 

‘-g’  This  specifies  that  a  symbol  table  should  be  included,  so  that  the  program 

can  be  debugged  using  ‘dbz’. 

‘-0’  This  specifies  that  the  program  should  be  optimized  to  improve  execution 

speed.  The  exact  version  of  this  flag  differs  between  machines,  and  some 
machines  do  not  allow  this  flag  together  with  -g.  On  an  SGI  or  a  Mips,  the 
flags  ‘-g3  -02’  will  yield  the  maximum  optimization  which  current  compiler 
versions  can  perform  on  ModSAF.  WARNING:  Optimized  code  generally 
cannot  he  debugged  reliably  using  dbx. 

‘-mip82’  Newer  versions  of  SGI  hardware  and  compilers  support  the  MIPS  II  in¬ 
struction  set.  If  you  have  such  a  machine,  the  ‘-otips2’  option  will  yield  up 
to  a  2x  performance  boost,  with  no  negative  effects.  This  argument  does 
not  interfere  with  debugging. 

See  the  Unix  manual  page  on  ‘cc’  for  more  information.  If  multiple  arguments  are 
used,  they  must  be  combined  with  quotations.  For  example: 

setenv  EXTRA.CFLAGS  ’-g3  -02 » 

If  you  do  not  set  these  environment  variables  yourself,  the  ‘make-all’  script  will  set  up 
a  standard  configuration  in  the  ‘.cshrc’  file  in  your  home  directory. 

Compile  the  ModSAF  software 

To  compile  the  ModSAF  software: 
cd  src/ModSAF 
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make-sdl 

If  necessary,  the  ‘oake-all*  script  will  set  a  few  necessary  environment  variables  and 
put  the  correct  ‘conmon/bin’  subdirectory  in  your  path  before  building  anything  (see 
Section  1.1.5  [lib],  page  3). 

‘make-all’  makes  the  ‘depends’  program,  many  software  libraries,  and  the  ModSAF 
application,  which  is  called  hnodaaf.arch’.  Where  axch  is  replaced  with  the  architecture 
you  are  building  on.  For  example,  the  executable  would  be  called  ‘modsaf  .sgi’  for  the 
Silicon  Graphics  architecture. 

You  will  get  an  error  message  in  certain  libraries  which  do  not  have  TeXinfo  documen¬ 
tation,  as  the  build  process  attempts  to  generate  Info  documentation  in  every  library. 
These  error  messages  can  be  safely  ignored. 

When  the  build  is  complete,  the  modsaf  application  will  be  test  run  to  have  it  display 
its  arguments  and  verify  that  the  executable  does  run. 

Install  the  simle  driver  (Sun  only) 

If  you  are  running  ModSAF  on  a  SPARC  based  SunOS  4.1.1  (or  higher),  you  can 
use  the  installable  simle  driver  to  send  and  receive  SIMNET  libassoc  packets.  There 
are  several  files  used  to  load  the  simle  driver,  all  of  which  are  in  the  directory  com- 
mon/src/simle/dvr: 

‘siml«_rc’ 

Contsdns  the  lines  that  should  be  put  into  the  file  /etc/rcJocal  to  load  the 
driver  at  boot  time. 

‘sifflle.load’ 

A  script  to  do  the  loading,  which  should  live  in  /etc. 

‘sifflle.mknod’ 

A  script  to  make  the  necessary  "/dev/simle*"  file,  which  should  live  in 
/etc. 

‘simle. o’  The  driver  object,  which  should  live  in  /etc. 

‘simle. install’ 

A  script  to  put  the  above  3  files  in  /etc,  add  the  contents  of  simle.xc  to 
/etc/rc.local  (if  not  already  there),  execute  /etc/simleJoad,  and  configure 
up  to  2  othcrnei  cards  that  may  be  present.  This  change  to  rcJocal  is 
permanent  and  means  the  simle  driver  will  be  loaded  into  the  kernel  each 
time  the  m.achine  is  rebooted.  You  must  be  root  to  run  this  script. 

To  install  this  driver,  run  the  simle.install  script  as  root. 

Use  the  xinfo  documentation  tool 
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Determine  the  absolute  info  path  where  the  info  sources  have  been  installed.  If  you 
installed  the  software  in  Vusr/staff/nynana/fflodsaf the  <a.bsoIute-info-path>  will 
be  Vusr/st  2if  f /mynama/mods  af  /coomon/  inf  o  ’. 
cd  /usr/staff/mynama/modsaf 

comnon/bin/zinfo  -fila  nodaafdir  -path  <absoIute-info-path> 

You  may  click  on  various  text  nodes  to  follow  the  ModSAF  documentation  tree.  When 
finished,  click  "quit"  to  exit. 

Customize  emacs  to  use  info  documentation: 

If  you  are  unfamiliar  with  the  use  of  Info  in  emacs,  you  can  enter  emacs  and  type 

i.  Read  the  instructions  and  type  h  to  get  a  tutorial  on  the  use  of  Info. 

To  access  modsaf  info  documentation  from  emacs,  you  will  have  to  edit  the  dir  info 
node  to  access  the  modsaf  dir  info  node: 

1.  Enter  emacs.  To  find  the  filesystem  location  of  the  dir  node, 

2.  Type  “h  i  This  will  bring  you  into  the  info  system  at  the  dir  node. 

3.  Type  ‘z'b  to  get  a  buffer  list.  The  absolute  pathname  of  the  dir  node  will  be 
listed. 

4.  Exit  emacs.  As  root,  you  can  edit  the  ‘dir’  file  in  the  directory  identified  in  the 
previous  step  to  add  the  following  line  to  the  end  of  the  file: 

*  ModSAF :  (<absoiute-info-path>/modsaf  dir)  . 

Documentation  about  ModSAF. 

Once  the  dir  node  is  modified,  emacs  will  be  able  to  access  the  modsaf  info  sources 
directly: 

1.  Enter  emacs 

2.  Type  “h  i 

3.  Type  m,  followed  by  modsaf  to  enter  the  modsaf  node. 

Create  /etc/assoc.def 

Create  the  file  Vet  c/assoc,  def’  file  which  will  describe  the  simulation  site  and  host 
of  the  machine  which  will  run  the  ModSAF  application.  Site  numbers  are  typically 
assigned  to  a  site  by  Loral.  Host  numbers  are  assigned  by  the  site  manager  at  a  given 
site.  As  an  example,  if  you  are  site  1  and  the  machine  you  are  on  is  host  5,  you  can 
create  the  ‘assoc. def’  file  as  follows  (as  root): 

cat  >  /atc/assoc.def 
site  1 
host  5 
‘D 

Configure  the  real  time  clock  (SGI  only) 

The  SGI  operating  system  defaults  to  an  extremely  low  clock  resolution  of  10  ms.  This 
can  be  fixed  using  the  command  */etc/ftimer  -f  on’.  This  command  requires  root 
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privileges.  You  can  set  up  the  machine  to  automatically  fix  the  real  time  clock  by 
creating  a  boot-up  initialization  script: 

cat  >  /•tc/rc2.d/S99ftia«r 
/etc/ftiffler  -f  on 
/etc/ftiaar 
“D 

chaod  *x  /•tc/rc2.d/S99f timer 
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1.4  Running  ModSAF  1.0 

If  you  are  running  on  an  SGI  system,  and  you  want  to  use  the  network,  you  must  login  as  root. 
Remeber  that  as  root,  any  command  you  issue  from  the  current  directory  must  begin  ./<command>. 
Once  the  ModSAF  program  hais  been  successfully  compiled,  it  can  be  run  from  the  directory 
‘coamon/src/ModSAF’.  There  are  actually  two  ModSAF  programs,  which  are  combined  into  a 
single  executable.  For  the  Mips  architecture,  the  executable  file  is  called  ‘modsaf.mips’;  for  the 
SGI,  ‘nodsaf  _8gi’,  and  so  on.  The  two  ModSAF  programs  are: 

SAFSt&tioa 

This  is  the  ModSAF  user  interface.  This  program  provides  a  map  display,  and  allows 
a  user  to  create  units,  missions,  and  make  assignments  to  ModSAF  vehicles. 

SAFSim  This  is  the  ModSAF  vehicle  simulation  program.  This  program  creates  SAF  vehicles 
in  response  to  requests  from  the  SAFStation  program  (or  other  programs  running  on 
the  network),  and  controls  the  behavior  of  those  units. 

For  testing,  these  two  programs  can  be  run  together  on  a  single  computer.  However,  such  a 
configuration  may  not  be  able  to  meet  real-time  simulation  requirements  because  of  the  burden  of 
user  interface  processing. 

The  ModSAF  user  interface  uses  the  X  resource  manager  for  selection  of  layout,  sizing,  coloring, 
etc.  The  resources  used  by  ModSAF  can  be  found  in  the  file  ‘comaon/src/HodSAF/ModSAF*.  If  you 
are  using  a  machine  with  X  windows  version  X11R5,  you  can  set  up  the  system  to  automatically 
load  this  file  when  the  program  starts  by  adding  the  following  to  your  ‘ .  cshrc’: 

setenv  XAPPLRESDIR  . 

or  if  you  use  a  variant  of  sh,  add  this  to  your  *.prof  ile’: 

XAPPLRESDIR-. 
export  XAPPLRESDIR 

If,  however,  you  are  using  X  windows  version  X11R4,  a  bug  in  the  X  resource  manager  pre¬ 
vents  this  from  working.  On  such  machines,  you  must  use  the  xrdb  command  every  time  you 
login.  The  executable  for  xrdb  will  be  found  in  your  Xll  bin  directory,  either  /usr/Xll/bin,  or 
/usr/local/Xl  1/bin.  This  directory  should  replaced  <Xbindir>  in  the  command  below: 

cd  /usr/staff/mynaffle/modsaf/comaon/src/NodSAF 
/<Xblndir>/zrdb  -merge  ModSAF 
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The  above  two  commands  need  to  be  done  anytime  you  login,  after  logging  in,  to  configure  the  X 
server  to  use  the  default  resources. 


1.4.1  Command  Line  Arguments 

The  ModSAF  program  takes  many  command-line  arguments,  most  of  which  are  described  in 
the  following  sections.  The  default  values  for  these  arguments  are  compiled  into  the  ModSAF 
program,  but  can  be  overridden  with  an  environment  variable.  The  name  of  the  environment 
variable  depends  on  your  architecture.  The  Silicon  Graphics  Architecture  uses  MODS AFSGI ARCS, 
the  Mips  uses  MQDSAFHIPSARGS,  and  the  SUN  architecture  uses  MOOSAFSUN4ARGS.  For  example,  to 
change  the  default  terrain  database  to  knox-0311  on  an  SGI,  add  the  following  to  your  ‘.cshrc’; 

setenv  MQDSAFSGIARGS  '-terrain  knoz-0311* 

or  if  you  use  a  variant  of  ‘sh’,  add  this  to  your  ‘.profile’: 

M00SAFSGIARGS«' -terrain  knox-0311* 
export  NODSAFSGIARGS 

For  an  overview  of  the  command  line  arguments  and  to  see  their  default  values,  use  (the  program 
name  varies): 

cd  coomon/src/NodSAF 
oodsaf.sgi  -help 


1.4. 1.1  SAFStation 

The  command  line  argument  -gui  selects  the  SAFStation  functionality.  To  disable  the  SAFS¬ 
tation,  instead  use  -nogui. 

In  addition,  all  standard  X  windows  command  line  options  are  supported.  For  example,  to  set 
the  display  device,  use  -display  machineiO. 


1.4. 1.2  SAFSim 


The  command  line  argument  -sinulate  selects  the  SAFSim  functionality.  To  disable  the  SAF- 
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Sim,  instead  use  -nosim. 

Another  command  line  argument  which  impact  the  simulation  is  the  simulation  loading  factor 
-load  floating  point  number.  This  option  specifies  the  portion  of  maximum  simulation  load  im¬ 
posed  by  one  simulated  vehicle,  and  is  used  in  the  inter-machine  load  balancing  algorithm.  Since  a 
typical  workstation  can  support  about  60  local  vehicles,  the  value  1/60  (0.167)  is  used. 


1.4. 1.3  Networking 

I  The  ModSAF  program  can  be  configured  to  support  many  different  networking  schemes.  To 

select  a  networked  ModSAF,  use  the  option  -netuork.  To  disable  networking  use  -nonet. 

I 

^  The  network  device  can  be  selected  with  the  argument  -natdev  device.  The  appropriate  network 

device  varies  on  different  machines. 

I 

I 

The  DIS  and  SIMNET  protocols  support  multiple  simultaneous  exercises  running  on  a  single 
.  network.  To  specify  the  exercise  in  which  a  ModSAF  should  participate,  use  the  command  line 

>  option  -exercise  1-254. 

I 

\  The  ModSAF  system  uses  the  Persistent  Object  protocol  for  communications  between  SAFSims 

and  SAFStations.  The  protocol  allows  multiple  simultaneous  persistent  object  databases  within  a 
I  single  exercise.  All  ModSAF  computers  which  are  using  the  same  database  will  work  together  to 

I  do  SAF  simulations.  To  specify  the  database  being  used  by  a  set  of  ModSAF  simulators,  use  the 

command  line  option  -database  1-254. 

Simulation  protocols  must  use  an  application  layer  protocol  to  move  packets  between  computers. 
In  SIMNET  this  function  was  performed  by  the  Association  Layer  Protocol  (libassoc).  In  DIS, 
for  the  time  being,  this  function  is  being  performed  with  the  Internet  User  Datagram  Protocol 
(UDP/IP).  The  ModSAF  software  allows  either  protocol  to  be  used,  regardless  of  whether  SIMNET 
I  or  DIS  simulation  protocols  are  being  used.  To  use  the  Association  Layer  Protocol,  use  -assoc 

-noudp.  To  use  the  User  Datagram  Protocol,  use  -udp  -noassoc. 

Note  that  the  Association  I.ay<*r  Protocol  requires  a  modified  operating  system  kernel  on  the 
Mips  Magnum,  and  extra  harilw,ir«'  .in<f  .i  fiiotiified  kernel  on  the  Mips  M/2000. 

1 

Using  the  Association  Layer  ProtiM-ol  on  a  Sun  requires  some  extra  configuration  (see  Section  1.3 
I  [Building  ModSAF  1.0],  page  9i 
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The  UDP  networking  software  can  run  either  asynchronously  (driven  by  software  signals  gen¬ 
erated  by  the  operating  system),  or  via  polling.  The  performance  characteristics  of  each  method 
will  differ  between  different  operating  systems.  To  select  asynchronous  operation  use  -aaynch;  for 
polling,  use  -synch. 

No  standard  exists  for  which  UDP  port  should  be  used  for  transmitting  different  protocols 
(although  3000  is  most  common  for  DIS).  To  select  the  port  for  DIS  protocol,  use  -disport  port. 
To  select  the  port  for  PO  protocol,  use  -poport  port  -noexperimental.  To  select  the  port  for 
Stealth  protocol,  use  -stealthport  port. 

Another  option  for  transmitting  the  PO  protocol  under  UDP/IP  is  to  pack^e  all  PO  packets 
into  a  single  experimental  DIS  PDU  kind.  To  do  this,  use  -•zperimantal  kind  (134-255). 

The  ModSAF  program  supports  both  SIMNET  6.6.1  and  DIS  protocols.  To  use  DIS,  use  -dis. 
For  SIMNET,  use  -sismet. 

The  current  defacto  standard  DIS  version  is  that  used  at  the  I/ITSEC  ’93  interoperability 
demonstration  (DIS  2.0.3).  Although  this  version  is  the  default,  it  can  be  selected  by  using  the 
-version  3  option.  To  select  the  ITSEC  ’92  version  (DIS  1.0),  use  -version  1.  Note  that  these 
two  versions  are  not  compatible.  Every  computer  on  the  network  must  be  using  the  same  version 
of  the  DIS  protocol  for  interoperation.  DIS  version  2.0.2  (-version  2)  is  no  longer  supported. 


1.4. 1.4  Terrain 

The  terrain  database  can  be  selected  with  the  command  line  option  -terrain  name.  The  name 
can  be  the  name  of  a  terrain  database  in  the  directory  ‘common/terrain’,  or  it  can  be  the  absolute 
pathname  of  a  terrmn  database  directory  (starting  with  V’). 


1.4. 1.5  Site  Customization 

The  simulation  address  for  a  machine  should  be  set  in  the  file  Vetc/assoc.def’.  This  address 
can  be  overridden  with  the  command  line  option  -simaddr  site  (1-65535)  host  (1-65535). 

The  ModSAF  user  can  create  user  interface  profiles  (for  example,  the  default  coordinate  sys¬ 
tem,  metric  vs  English,  etc.),  and  save  them  to  disk.  The  default  directory  for  these  files  is 
‘cosnon/profiles’,  however  this  can  be  overridden  with  -profile  directory. 
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The  ModSAF  user  can  save  scenarios  (created  units  and  command  graphics)  to  disk.  The  default 
directory  for  these  files  is  ‘conmon/scenarios’,  however  this  can  be  overridden  with  -scenario 
directory. 

Some  features  of  the  ModSAF  user  interface  require  privileges  to  access.  These  privileges, 
are  password  protected,  by  default.  The  default  password,  for  historical  reasons,  is  ‘foozball’. 
This  password  can  be  modified  by  creating  a  file  in  the  ‘conmon/src/HodSAF’  directory  called 
‘  .password’.  For  example,  to  change  the  password  to  ‘f  rabnitz’,  type: 

cd  common/src/ModSAF 
cat  >  .password 
frabnitz 
‘D 


To  disable  password  protection,  create  an  empty  ‘.password’  file: 


cd  common/src/NodSAF 
rm  -f  .password 
touch  .password 


1.4.2  Configuring  ModSAF 

By  default,  when  the  ModSAF  program  is  run  from  the  directory  ‘comaon/src/NodSAF’,  data 
files  ending  in  ‘ .  rdr ’  are  loaded  from  the  directory  ‘ . .  / . .  /data’,  which  translates  to  ‘conmon/data’. 
However,  these  data  files  can  be  overridden  by  placing  modified  versions  in  the  directory  from  which 
the  program  is  run.  Instead  of  loading  the  default  files,  the  modified  versions  will  be  loaded. 

The  default  X  resources  used  by  ModSAF  can  be  overridden  using  the  X  resource  manager. 
Typically,  this  is  done  by  placing  resource  modifications  in  a  user’s  ‘.zresourcea’  file.  The  exact 
name  of  a  widget  resource  can  be  found  by  looking  in  the  ‘.xrdb’  file  which  configures  the  widget 
by  default.  Also,  some  possible  X  resource  customizations  are  described  in  the  ModSAF  library* 
TeXinfo  documentation. 


1.4.3  Known  Problems 

The  following  is  a  list  of  known  problems  with  the  ModSAF  1.0  release. 


•  The  execution  matrix  is  an  experimental  piece  of  software  which  has  several  known  problems: 
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-  A  mission  for  a  unit  cannot  be  saved  until  after  it  is  assigned. 

-  The  ability  to  edit  an  execution  matrix  after  it  has  been  assigned  is  extremely  limited. 
Many  editing  operations  will  have  undesired  effects. 

-  There  is  no  ability  to  specify  global  mission  parameters  such  as  fire  permissions,  or  enemy 
situation.  These  parameters  must  be  specified  for  every  frame. 

•  The  logger  has  the  following  list  of  problems 

-  The  logger  does  not  yet  support  The  DIS  2.0.3  protocol.  It  only  supports  Simnet  and  DIS 

1.0. 

-  Recording  over  part  of  an  existing  file  does  not  work. 

-  The  Internal  button  doesn’t  work  unless  the  Network  button  is  also  activated 

•  In  some  circumstances,  M2,  BMPl,  and  BMP2  will  attempt  and  fail  to  engage  targets  with 
missiles  when  the  target  is  not  in  the  same  plane/orientation  as  the  attacker. 

•  Due  to  the  use  of  absolute  elapsed  time  instead  of  relative  time,  the  task  state  for  VEnemy 
changes  more  frequently  than  necessary. 

•  Turret  scan  sectors  are  often  incorrect  during  road  marches. 

•  Parameter  changes  made  to  a  platoon  or  company  after  creation  are  not  propogated  down 
to  the  individual  vehicles.  For  example,  you  cannot  teleport  a  platoon  to  a  new  location  by 
editing  the  platoon. 

•  When  a  vehicle  is  shooting  at  an  enemy  and  runs  out  of  that  type  of  munition  it  will  not  shoot 
even  if  it  is  assigned  more  ammunition. 

•  There  are  a  few  munitions  that  are  currently  not  defined  in  the  vehicle’s  vassess  parameter  file. 
This  means  the  vehicle  can  not  shoot  that  munition. 

•  Many  soviet  formations  are  not  correct.  One  effect  of  this  is  that  vehicles  will  cross  paths  when 
occupying  a  position. 

•  The  "Conform  to  Terrain"  option  in  the  Move  task  frames  is  an  experimental  piece  of  software, 
which  often  leads  to  incorrect  movement. 

•  Occasionally  an  M2  will  not  start  moving  again  after  its  stops  to  fire  its  TOW  missile. 

•  Some  mixed  platoons  don’t  have  the  right  force  id  (friendly/enemy). 

•  You  can’t  stop  a  air  to  air  intercept  with  the  STOP  REACTION  button. 

•  Tanks  cannot  shoot  DI  yet.  (US  M59,  USSR  D)  They  have  a  weapon  for  it,  but  it  is  not  listed 
in  the  vehicle’s  VAssess  section  of  the  rdr  file. 

•  Selecting  a  stealth  from  the  map  display  when  the  Unit  Operations  menu  is  present  will  lead 
to  overlapping  control  menus.  Exit  the  Unit  Operations  menu  before  choosing  a  stealth. 

•  After  executing  several  hard  turns,  the  fixed  wing  aircrafts  may  lose  altitude  and  may  not  be 
able  to  recover. 

•  Fixed  wing  aircraft  can  not  perform  the  task  "Fly  Route".  If  assigned  this  task,  they  will  just 
sit  there.  FWA  should  only  be  assigned  "Sweeep",  "Cap",  and  "Return  to  Base". 
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•  Rotary  wing  do  not  currently  have  a  landing  task.  They  can  only  be  told  to  return  to  base. 

•  Rotary  wing  aircraft  performing  takeoff  right  now  will  either  spin  a  bit,  or  bump  the  ground. 
They  will  then  perform  normally. 

•  Rotary  wing  aircraft  performing  a  fly  route  will  occasionally  in  pasing  a  route  point  turn 
around  and  go  back  to  it,  then  continue  on  their  route. 
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1.5  Porting  ModSAF  1.0 

The  ModSAF  software  is  quite  portable.  It  uses  K&R  C,  with  modest  extensions  (such  as  unique 
identifiers  which  exceed  8  characters). 

X  windows  is  used  exclusively  for  windowing  (SGI  GL  is  not  used).  X  versions  4  and  5  both 
work  well  with  ModSAF  (R5  seems  to  have  improved  performance  on  the  Mips  platform).  The 
OSF/Motif  1.1  widget  set  is  used. 

The  first  step  in  porting  ModSAF  to  a  new  platform  is  to  edit  the  configuration  in  the  ‘coimnon/tools’l 
directory.  Most  of  the  configuration  parameters  are  in  the  file  ‘make.conf  ig’.  This  file  include  spec¬ 
ification  of  the  C  compiler  and  options. 

You  must  give  a  name  to  the  new  architecture,  for  example,  if  you  are  porting  to  a  Hewlett 
Packard  operating  syste,  you  could  call  the  architecture  ‘hp’. 

The  application  description  file  (such  as  'common/src/ModSAF/modsaf  .config’)  must  include 
this  new  architecture  name  in  the  list  of  supported  architectures  (ARCHLIST). 

Edit  the  file  *coDmon/tools/mak«.conf  ig’  to  include  any  special  compiler,  linker,  archiver,  etc. 
directives.  In  the  middle  of  this  file  you  will  find  a  set  of  flag  settings  for  each  architecture.  Copy 
an  existing  architecture  and  modify  it  as  needed.  This  may  include  some  of  the  following: 

One  common  change  is  for  machines  which  do  not  have  the  single-precision  square  root  function, 
fsqrt.  On  such  machines  add  the  definition  -Dfsqrt^sqrt  to  the  <arcb>_CFLAGS. 

Another  difference  between  machines  is  whether  they  have  or  need  the  command  ‘ranlib'  exe¬ 
cuted  on  library  archives.  This  is  selected  by  the  <arch>.RL  and  <arch>_RLFLAGS. 

It  is  unlikely  that  a  new  machine  will  be  able  to  easily  support  the  SIMNET  Association  Layer 
Protocol,  because  it  requires  access  to  raw  802.3  Ethernet  packets.  On  such  machines,  skip  the 
compilation  of ‘libnetif 'libassoc'.  and  ‘libp2p’  and  add  -DNO.ASSOC  to  the  <arch>_CFLAGS. 

Another  common  difference  h«*twoon  unix  systems  is  whether  the  string  operation  header  file  is 
called  ‘string. h’  or  ‘strings. h*.  If  ii  is  the  former,  then  add  the  definition  -DUSESTRINGDOTH  to 
the  <arch_>CFLAGS. 

Once  the  tools  directory  is  s«>t  up  for  a  machine,  most  directories  should  compile  without  mod- 
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1.6  Printing  ModSAF  Documentation 

The  complete  ModSAF  documentation  set  is  roughly  1000  pages,  so  it  makes  sense  to  only 
print  documents  selectively.  The  documents  are  written  using  the  TeXinfo  documentation  system. 
Printing  the  documents  requires  access  to  the  I^C  software  package.  TeX  is  available  from  the 
University  of  Washington,  for  a  small  fee. 

You  will  need  the  input  file  ‘texinfo.tex’.  If  you  do  not  have  this  file,  one  has  been 
provided  in  ‘common/bin’.  Copy  this  to  the  directory  where  looks  for  input  files  (often  in  a 
directory  called  ‘inputs/’,  or  ‘macros/’). 

There  sire  rules  in  each  ‘Makefile’  which  can  translate  the  ‘.texinfo’  documents  into  ‘.dvi’ 
documents,  the  output  of  For  example,  to  generate  the  documentation  for  ‘libctdb’,  use; 

cd  common/libsrc/libctdb 
make  libctdb. dvi 

‘.dvi’  files  must  be  translated  to  a  printer’s  native  language  before  they  can  be  printed.  One 
tool  commonly  used  for  this  translation  is  ‘dvi2ps’.  Several  conversion  tools  are  included  in  the 
lyC  distribution. 
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1.7  Troubleshooting 

When  I  compile  an  individual  library,  I  get  lots  of  error  messages 

The  ModSAF  MaJcehles  now  expect  to  use  the  GNU  maJce  program,  gmake.  Did  you 
compile  with  ‘gmadta’? 

Are  the  BUILD.ARCH  and  BUILD.APP  environment  variables  set  correctly? 

Is  the  correct  ‘bin’  subdirectory  in  your  path? 

See  Section  1.3  [Building  ModSAF  1.0],  page  9. 

See  Section  1.1.5  [lib],  page  3. 

See  Section  1.1.8  [bin],  page  6. 

When  I  start  the  program  with  -gui  I  get  an  X  error. 

The  user  interface  is  all  mashed  up  into  the  upper  left  screen  corner. 

If  you  are  using  Xll  R4,  did  you  run  ‘xrdb  -merge  ModSAF’? 

If  you  are  using  Xll  R5,  did  you  ‘setenv  XAPPLRESDIR  .’? 

See  Section  1.4  [Running  ModSAF  1.0],  page  14. 

When  I  start  the  program  under  ‘dbx’I  get  an  I/O  error. 

The  asynchronous  UDP  implementation  uses  the  SIGIO  signal  to  receive  incoming 
packets,  ‘dbx’  can  be  told  to  ignore  this  signal  by  adding  the  command: 
ignore  23 

to  the  file  ‘.dbxinit’  in  your  home  directory. 

I  get  a  warning  from  *cpp’  about  redefinition  of  M-PI. 

I  get  a  warning  from  ‘cpp’  about  redefinition  of  NULL. 

These  warnings  have  been  seen  on  the  SGI,  and  we  have  not  yet  identified  where  the 
redefinition  is  occurring.  They  can  be  safely  ignored. 

My  C  compiler  dies  with  a  "symbol  table  full"  error. 

The  ModSAF  program  is  very  large,  and  has  been  known  to  choke  compilers.  Check 
your  operating  system  reference  manuals  to  see  if  the  compilers  limits  can  be  increased. 
My  C  compiler  dies  with  an  internal  error  while  linking. 

Some  C  compilers  use  the  directory  ‘/tmp’  for  storing  internal  files  during  compilation. 
There  may  not  be  enough  space  in  the  root  partition  to  hold  some  of  these  files.  If 
this  is  the  case,  the  compiler  can  often  be  told  to  redirect  temporary  files  to  a  different 
directory  (the  Mips  uses  the  environment  variable  TMPDIR). 

I  can ’t  lint  the  ModSAF  program. 

Although  there  is  a  lint  target  in  each  library,  many  of  the  libraries  include  many  X 
and  Motif  header  files,  which  can  overwhelm  lint.  The  intarck  program  finds  many  of 
the  same  errors  lint  can  find,  and  many  more. 

‘dbx’  shows  incredible  values  for  local  variables. 

‘dbx’  complains  that  the  program  has  no  symbol  table. 

By  default,  the  ModSAF  program  is  set  up  to  compile  with  optimization.  This  makes 
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use  within  a  debugger  difficult  or  impossible.  Change  the  definition  of  your  environment 
variable  EXTRA.CFLAGS  to  include  a  symbol  table  (usually  ‘-g’)  and  omit  optimization. 
See  Section  1.3  [Building  ModSAF  1.0],  page  9. 

Network  performance  at  my  site  degrades  badly  when  I  run  ModSAF. 

The  DIS  protocols  currently  use  broadcast  UDP/IP  for  packet  transmission.  These 
packets  will  be  received  by  every  computer  on  the  network,  and  some  may  respond 
with  "I  hear  you  but  I  don’t  know  why  you  are  telling  me"  packets  (Mips  RISC/OS 
does  this).  The  SIMNET  Association  Layer  Protocol,  in  contrast,  is  multicast  so 
that  only  those  computers  which  explicitly  ask  for  the  packets  will  hear  them.  The 
ModSAF  program  allows  the  DIS  protocol  to  be  sent  using  the  SIMNET  Association 
Layer  Protocol  (as  protocol  family  3)  with  the  command  line  arguments  -assoc  -noudp 
-dis. 

See  Section  1.4. 1.3  [Networking],  page  16. 

I  need  to  run  in  an  area  for  which  no  terrain  database  is  available. 

The  library  ‘common/libsrc/libctdb’  contains  a  program  called  ‘ocean’,  which  can 
be  used  to  create  nominal  (flat)  databases  anywhere  in  the  world.  Go  to  that  directory, 
‘make  ocean’,  and  run  ‘ocean  -help’  for  details. 

How  can  individuals  use  different  compiler  configurations? 

The  environment  variables  EXTRA.CFLAGS  and  EXTRA.LDFLAGS  can  be  set  by  different 
users  to  augment  the  compilation  process.  These  flags  are  used  in  addition  to  those 
specified  in  ‘common/tools/Dake.config’. 

ModSAF  says  it  is  out  of  cycles. 

This  is  a  normal  error  which  indicates  that  the  simulation  capabilities  of  the  ModSAF 
program  have  been  exceeded.  Performance  can  be  improved  on  some  architectures  by 
using  optimization  and  special  compiler  directives  (such  as  -mips2  on  the  SGI).  Also, 
SGI  users  may  encounter  this  error  if  the  fast  ftimer  is  not  turned  on  (See  Section  1.3 
[Building  ModSAF  1.0],  page  9). 
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